%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Iteration 4
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Iteration 4: Interbank Transaction System (P2)}
        
        
In the fourth iteration we decompose the \emph{Interbank Transaction System}. For this decomposition we consider QaS P2: "Processing credit instructions and/or credit instruction status updates from other banks". The use cases relevant to this are:        
\begin{itemize}
	\item UC23: Send interbank credit instruction
	\item UC24: Receive status update for interbank credit instruction
	\item UC25: Process interbank credit instruction
\end{itemize}

These drivers can be summarized in the following requirements:
\begin{itemize}
	\item Processing of credit instructions should not interfere with the normal, operational transaction processing.
	\item The processing of status updates should not interfere with normal transaction processing.
	\item Credit instructions should be processed within one working day.
	\item Credit status updates should be processed so that the complete transaction is executed within 3 working days.
	\item The system notifies the customer of a failed transaction.
	\item Status updates are handled correctly.
	\item Interbank transactions are correctly handled.
\end{itemize}


To satisfy this driver we considered different performance tactics to find an appropriate solution.
\begin{description}

	% Tactic problem
    \item[Resource demand:] We do not control the incoming credit instructions or status updates, no credit instructions and status updates can be lost and we want to process them as fast as possible. We can however control the load on the network.
    
        \begin{description}
            % solutions for problem
            \item[Manage event rate:] We can manage the network load by grouping outgoing status updates together in batches to be sent with the \emph{SWIFT Communication} component.
        \end{description}
        
        
    % Tactic problem
    \item[Resource management:] Incoming credit instructions and status updates will be converted into transaction commands and processed by the \emph{Transaction Processing System}. The \emph{Transaction Processing System} already supports concurrency and multiple copies of computations to process multiple transaction commands at the same time. It also supports the increase of available resources.
    
        \begin{description}
            % solutions for problem
            \item[Introduce concurrency:] The translation of batch instructions and status updates can be done concurrently. Multiple translators can process multiple batches in parallel and send all resulting commands to the \emph{Transaction Processing System}.
            \item[Increase available resources:] Translators can be added and removed according to need.           
        \end{description}


    % Tactic problem
    \item[Resource Arbitration:] The \emph{Transaction Processing System} already uses dynamic priority scheduling to schedule the incoming transaction commands.
    
        \begin{description}
            % solutions for problem
            \item[Fixed-priority scheduling:] Batches will be translated according to semantic importance. It is not possible to do dynamic scheduling at this stage because we can't determine a deadline, but the difference between POS requests and interbank instructions can be made.
        \end{description}
        
\end{description}



\begin{figure}[!hb]
    \centering
        \includegraphics[width=0.8\textwidth]{images/It4_P2_componentdiag.png}
    \caption{Component diagram after iteration 4.}
    \label{fig:It4_P2_componentdiag}
\end{figure}

Incoming SWIFT messages are stored and forwarded to either the \emph{POS System} or the \emph{Interbank Transaction System}. Messages destined for the \emph{POS System} are given higher priority. Note that most of the performance features needed to handle POS payments, Credit instructions or Credit instruction status updates are already provided by the \emph{Transaction Processing System}. This \emph{Transaction Processing System} processes transaction commands and updates the \emph{Balance Database} or \emph{Transaction Database} if necessary.

The \emph{Interbank Transaction System} will handle the incoming Credit instructions and Credit instruction status updates that are received by \emph{SWIFT Communication} [see figure \ref{fig:It4_P2_componentdiag}]. Both credits and status updates will be translated into transaction commands that can be processed by the \emph{Transaction Processing System}. The \emph{Transaction Processing System} will process the transaction commands and update the necessary data. Transaction commands can be easily extended to allow for status updates to be processed.

The \emph{Transaction Handler} will process these status updates by updating a status field with the corresponding transaction in the \emph{Transaction Database} to success if the status update notifies of success. In the case that the status update notifies a failure, the \emph{Transaction Handler} will undo the failed transaction by reimbursing the money, updating a status field with the corresponding transaction in the \emph{Transaction Database} to failed, and send out a message through \emph{Send Notification} to notify the customer of the transaction failure.

To allow the translation of SWIFT messages we decompose the \emph{Interbank Transaction System} so that it has a \emph{Interbank Message Parser} which implements the Message Translator pattern. This \emph{Interbank Message Parser} processes batches of credit instructions and/or credit instruction status updates and translates them to individual transaction commands that are passed to the \emph{Transaction Processing System}. This \emph{Interbank Message Parser} can run multiple translators concurrently if multiple batches need to be translated in parallel.

The \emph{Interbank Message Generator} will accept status updates, credit instructions and possibly other interbank instructions from SAB and translate them into SWIFT messages. These status updates and instructions can be grouped in batches to be send over SWIFT.

Requirements can be divided over relevant components as follows:
\begin{itemize}

	\item \emph{SWIFT Communication}
	\begin{itemize}
		\item Av1: Interbank communication failure
	\item UC23: Send interbank credit instruction
	\item UC24: Receive status update for interbank credit instruction
	\item UC25: Process interbank credit instruction
	\end{itemize}
	
	
	\item \emph{Interbank Message Parser}
	\begin{itemize}
		\item P2: Processing credit instructions and/or credit instruction status updates from other banks
		\item UC24: Receive status update for interbank credit instruction
		\item UC25: Process interbank credit instruction
	\end{itemize}
	
	
	\item \emph{Interbank Message Generator}
	\begin{itemize}
		\item UC23: Send interbank credit instruction
		\item UC25: Process interbank credit instruction
	\end{itemize}
\end{itemize}





